Industrial devices such as temperature or pressure sensors are accessed by a client using an Internet Protocol (IP) Address or DNS symbolic name (machine.company.com). If a unit needs to be replaced, the replacement must appear to have the same IP Address as the predecessor to allow operations to proceed automatically. Typical maintenance personnel are not qualified to manipulate IP Addresses and must defer to Information Systems (IS) department or other network specialists. This causes a significant delay in connecting devices, which results in factory down-time. Alternatively, expensive specialists must be maintained around the clock to handle such problems.
The prior art encompasses several networking techniques. The Bootstrap Protocol (BOOTP) is an established method for assigning IP address and other key networking parameters to a device where the only information known about the device is its Ethernet Media Access Control (MAC) address. The protocol was invented by Sun Microsystems in 1985 to support diskless UNIX workstations. It is available as an option on most software products intended for use in embedded (no operator terminal) applications.
The Dynamic Host Configuration Protocol (DCHP) is a standard for networking communications. DCHP is a compatible extension to BOOTP and queries in DCHP form can be generated by devices using modern operating systems such as Windows CE or LINUX.
DCHP is primarily used for laptop computers or office systems in large companies where the addresses are ‘leased’ for a period of time rather than being assigned indefinitely. Likewise, the Simple Network Management Protocol (SNMP) is intended to allow Network Administrators to find and adjust key networking parameters on devices already installed on a network, particularly the routers, bridges, and hubs which form the infrastructure of the network. The JetAdmin Network Printer tool is a Hewlett-Packard system for reporting printer errors and administrating usage.
Reverse ARP (RARP) is an older protocol than BOOTP and intended for devices that did not require any configuration other than the IP address assignment. RARP is not as widely used as BOOTP because the tools to implement RARP are not as commonplace. RARP is implemented on some embedded system protocol stacks, wherein the supervisory server may respond with a RARP response if interrogated using a RARP request for a given MAC address.
The MAC address is a key identification parameter of all devices on a network such as Ethernet. It is a 48-bit number that combines information about the vendor and a unique unit sequence number, and is permanently allocated by the manufacturer of the network interface itself. It is not normally related in any way to the serial number or similar representation that a device might require for other reasons. The MAC address is conventionally expressed as a hexadecimal representation that is hard for non-specialists to handle. The Ethernet hardware uses the MAC address to determine which network messages are intended for specific delivery (unicast) to this station.
PING is another Internet protocol used for periodic interrogation of an IP device as an alternative to repeated use of the ARP request. There is little practical benefit for using PING, as the ARP messages are faster and less intrusive. All modern IP devices will respond to an ARP request because it is the only way to determine the MAC address.
An ‘Ethernet Switch’ or ‘Layer 2 switch’ is a device that transmits message packets unchanged from one of its ports to another, using rules that are dependent only upon the destination MAC address of the message. Such devices are becoming the preferred interconnection devices for large Ethernet networks, since they do not require significant configuration. This is as opposed to ‘routers’, otherwise known as ‘Layer 3 switches’.
A ‘Managed Ethernet Switch’ is an Ethernet switch which includes a management entity conforming to the reporting requirements of RFC 1493, and which therefore specifically may be interrogated to determine which port of the device was used recently to receive a message from a particular MAC address.
The protocol exchanges between the system components, namely the device, the managed switch, and the target IP unit are structurally defined in various standards documents. Software designers refer to these specifications when trying to implement software that encodes or decodes various messages. The Internet Request for Comment (RFC) documents are the standard form of documents for all communications using the Internet or TCP/IP.
The following table defines the primary applicable Internet protocol messages:
TABLE 1SNMP FindportARP RequestARP ResponseRequestSNMP FindportBOOTP RequestSee RFC 826See RFC 826See RFC 1493/1157ResponseSee RFC 951BOOTP ResponseMessage type =Message type =Message type =Message type =Message type =Message type =address resolutionaddress resolutionSNMP get objectSNMP get objectBOOT protocolBOOT protocolrequestresponse requestedrequestresponserequestresponseIP AddressDesired IPResolved MACObject ID =Object ID =Requesting MAC =Requesting MAC =address =address =.1.3.6.1.2.17.4.3.1.2..1.3.6.1.2.17.4.3.1.2.48 bit MAC address48 bit MAC address32 bit IP address48 bit MAC address(MAC as 6 decimal(MAC as 6 decimal(eg: 01:23:45:67:89:ab)(eg: 01:23:45:67:89:ab)(eg: 1.2.3.4)(eg: 01:23:45:67:89:ab)number 0–255)number 0–255)Object value = portAssigned IP = 32 bitnumber, or 0 if not foundIP Address
Alternatively, other Internet protocols messages are:
TABLE 2PING RequestDCHP RequestDCHPRARP RequestSee RFC 792PING ResponseSee RFC 2131/2132ResponseSee RFC 903RARP ResponseMessage type =Message type =Message contents =Message contents =Message type =Message type =ICMP ECHOICMP ECHOsame as BOOTPsame as BOOTPreverse addressreverse addressrequestresponseresolution requestresolution responseMessage dataMAC = 48 bitMAC = 48 bitunimportantMAC address (eg:MAC address (eg:01:23:45:67:89:ab)01:23:45:67:89:ab)Assigned IP =32 bit IP Address (eg:1.2.3.4)
There have been numerous attempts to provide an automatic addressing system. Many of the prior art systems employ non-IP means to set the address in advance, such as manually alterable switches, special connectors, front panel interface for manually entering addresses, and separate serial port interface for issuing an address. Although these existing means are satisfactory in some instances, they do not adequately address the industrial or factory market for devices such as sensors and I/O devices. And, it is not feasible or cost-effective to employ the existing addressing techniques into certain devices or certain environments.
Historically, almost all devices which have been attached to a TCP/IP network have been computer systems of some type, either of a ‘conventional’ (with keyboard and display) or ‘embedded’ (such as a network printer) type.
In order to make a TCP/IP device functional on a network, it is necessary to assign certain address parameters, most importantly the 32-bit IP address. In many cases additional parameters such as netmask, gateway, and Domain Name Server settings also need to be established. These settings are important for proper performance, otherwise the network becomes unstable and exhibits erratic behavior affecting the performance not just of the device being configured, but also other devices on the network.
The typical prior art sequence for manual assignment of the IP address and other networking parameters begins with the direct assignment of the IP Address using a local data entry port prior to attachment on the network. This is normally accomplished through the operator panel or user interface. The operator assigns the IP address by keystroke and confirms the settings before allowing communication on the network.
One prior art method of automatic assignment of IP addresses uses BOOTP or DHCP. The BOOTP or DCHP techniques require that a database be maintained separately that associates the ‘MAC address’ of the device to be attached with the required IP address and other parameters. This database is created and maintained by the network specialist and requires considerable skills that would not be held by the typical field replacement technician. In addition, DHCP cannot be used conventionally, to assign an ‘unpredictable’ address within a ‘pool’ of available addresses, because the primary network protocols between industrial devices, such as Modbus/TCP, use explicit knowledge of the IP addresses of the designated targets. For example, when DHCP is used on systems using Windows NT Server, the option known as ‘IP address reservation’ is typically used. This actually makes DHCP equivalent to BOOTP in this embodiment.
This prior art invention uses a central BOOTP or DHCP server to maintain a list of MAC addresses and IP addresses in a central location and allows acces by the experienced network or system administer to manage the lists. Although this protocol is implemented by many devices, the assignment must be done by the IS department or system administrator. In a factory environment with automated devices running 24 hrs a day×7 days a week, employing a system administrator to assign IP addresses on devices around the clock is not cost-effective. The technician or engineer replacing the device does not possess the adequate skill or knowledge to also assign the IP address, and having a device failure may cripple the plant operation. Businesses must minimize the downtime associated with field replacement of devices in order to make the production numbers. Delaying a factory line until a system administer can issue an IP address to the device is not a satisfactory option in the highly competitive marketplace.
Another prior art system of assigning IP addresses is done via indirect assignment using static address resolution protocol (ARP) override. The device is designed to ‘assume’ that any IP message arriving at the device that includes a MAC address that matches that of the device implies the registration of the IP address in the target. This forces the IP address sent to the device to be adopted by the device even if it is already in use. It also requires matching of the MAC address to the particular device. As noted herein, forcing the wrong IP address to a device on the network can result in unexpected catastrophe.
Typically the ARP override method involves an operator sequence at a management station such as:                arp-s 10.0.0.1 00:00:54:ab:cd:ef        ping 10.0.0.1This forces the local station to build a directed unicast message to the Ethernet address 00:00:54:ab:cd:ef and designate the IP address as 10.0.0.1. This is interpreted by the device with address OO:00:54:ab:cd:ef as authority to assign the IP address 10.0.0.1 Any internet protocol can be used during the second phase. Instead of PING, it is common to use TELNET on obscure port numbers in an attempt to avoid ‘accidental’ reconfiguration.        
There are also alternative network protocols for devices, such as HP JetDirect cards. The HP JetDirect cards use the IPX protocol to advertise their presence to any management station on the local network. A management program running on some station on the local network picks up the advertisement and displays the device as requiring configuration to the operator. Since typically only one station at a time on a network will be in an unconfigured state, this allows the operator to recognize and select that unconfigured device without recording the MAC address. All of these mechanisms require either knowledge of the MAC address of the device being attached, or at least specialized knowledge of the desired network function of the device by an operator. Use of an alternative protocol such as IPX will cause problems in use of the devices in environments where these protocols are not supported.
All the referenced techniques of IP Address assignment require either knowledge of the MAC address of the device being attached, specialized skills and training, or preferably both. IPX protocol implementations has some further inherent difficulty with devices not supporting IPX protocols on the network.
Industrial control devices pose particular problems because of the importance of operation, continuous operation, and location of the devices. These devices may fail in service and must be replaced rapidly from a spares stock with minimum Mean Time To Repair (MTTR). For example, the devices may fail because they are exposed to electrical or mechanical stresses that exceed their specifications. An example of a mechanical stress is being crushed by impact with a fork lift truck. A common example of an electrical stress is 110/220 V line power being shorted to low voltage input circuits. In such situations, the devices are usually designed to ‘go safe’, but they need to be replaced as rapidly as possible in order to allow the process to continue.
Most industrial users maintain a stock of spare devices of each type that need to be replaced. These users provide instructions to maintenance personnel for replacement of faulty devices. However, the need to assign IP addresses accurately under such critical replacement conditions is usually not practical. This is particularly true in industrial environments with strict responsibility partitioning between an electrician who can rewire a module, but requires the service of an IT technician to alter network parameters.
Previously, Ethernet was not considered a viable option to the business community. One problem with the implementation of Ethernet as a replacement for the device level networks such as ASi or DeviceNet was that you could not require anything more elaborate than the setting of a rotary switch to match the predecessor device. Such problems diminished as the protocols changed and expanded the Ethernet options.
One such protocol the industrial protocol MODBUS/TCP. MODBUS/TCP is a communication protocol designed to allow industrial equipment such as Programmable Logic Controllers, computers, operator panels, motors, sensors, and other types of physical input/output devices to communicate over a network. It was introduced by Schneider Automation in the early 1990's as a variant of the widely used MODBUS protocol, which had been implemented in turn by almost all vendors and users of automation equipment. The specification of the MODBUS/TCP variant was published on Schneider's web site, in order to encourage all vendors to implement the protocol consistently, and thus avoid interoperability problems that typically result when implementors must ‘deduce’ or ‘reverse-engineer’ an interface specification.
There have been several attempts to resolve the aforementioned problems. U.S. Pat. No. 5,410,730 ('730), discusses automating the initial assignment of a process device address by allowing a number of devices to be attached to the network, issuing queries to which all devices will respond, and then using unique parameters or serialization included in those devices before installation to assist an operator in assigning the network address.
The mechanism of the '730 patent requires foreknowledge of the unique characteristics of the device in order to provide address assignment, and cannot be used to perform automated assignment when replacing one of potentially many identical devices on a network segment. It is also not designed to work with TCP/IP local area networks. The mechanism of assigning a temporary address first, and then using that to complete the configuration process, is only necessary when using networks which have no native bootstrap address assignment process. In the case of a TCP/IP local area network, all of this functionality can be done using the Internet standard BOOTP protocol (RFC 951). With BOOTP, the information needed to perform the match is the serial number or ‘MAC address’ that is uniquely associated with the network interface hardware and readily available upon request.
U.S. Pat. No. 5,724,510, ('510) describes a technique which would most likely be banned in any practical Internet TCP/IP local area network because it assigns an address for a device by using speculation. Specifically, it deduces the range of addresses in use on the network to which the device is attached, and then issues a series of queries to determine whether a given address within that range has already been assigned to another device. The novelty claimed in the '510 patent is that in addition to the standard ARP technique ordinarily used to query the existence of a given IP address, the '510 system extends this by issuing a series of ‘application level’ queries. The reason for doing this is to overcome problems relating to the ‘cacheing’ of ARP records.
A flaw in the '510 invention is that it fails to address the case where the address being speculatively assigned has in fact already been assigned to another device, but that device is temporarily inaccessible, such as by being reset or through a temporary network disruption. The '510 system would complete its assignment of the duplicate address in a finite time period, after which, if the original device were to come back on line, there would be a duplicate address situation that would impede operation of the original device. This flaw supports the conclusion that it would likely never be permitted on a network used for automation purposes, as multiple devices with the same IP address would result in grave networking problems. A more appropriate solution to the assignment of an arbitrary address on a network is to use the Dynamic Host Configuration Protocol (DHCP) described in RFC 1531.
The invention of U.S. Pat. No. 5,446,897 ('897) allows for the assignment of the network address for a replaced device, automatically, by recognizing a unique ‘logical identifier’, or an ‘arbitrary word, number, or combination thereof’. One application of this '897 patent is the replacement of one of many identical devices on a network. Maintenance personnel set a plurality of switches or jumpers that are accessible on the device so that they have an identical setting to that on the device being replaced. Once completed, the application technique described in the '897 patent completes the replacement.
There are several limitations of technique of the '897 patent. Firstly, it requires that the devices being replaced incorporate the capability of reading some sort of ‘logical identifier’ before attempting address assignment. Secondly, the devices being replaced must incorporate a non-standard protocol capability to transmit that information to the management device for the purpose of address assignment. These two requirements severely limit the usefulness of the technique, since network administrators would be unwilling to deploy an automated configuration technique unless it applied to a high proportion of devices likely to require such assignment. Any attempt to make the requirements into a standard would require agreement among multiple vendors of equipment to adopt this additional feature voluntarily. Such cooperation would likely not succeed. The appropriate way of achieving such agreement is to propose the technique and get it adopted by a standards body such as the Internet Engineering Task Force (IETF). However, the IETF would be skeptical about the widespread adoption of such a technique because of its similarity to the BOOTP and DHCP protocols already available. In fact, the '897 patent describes a technique identical to the prior art of BOOTP, where the logical identifier is the MAC address.
A system for allowing decentralization of a directory previously maintained on a single file server is described in U.S. Pat. No. 6,021,429 ('429). Decentralization and resilience is achieved by arranging the ‘list servers’ to follow a defined protocol for determining the existence of list servers on a network. And, updating their contents from one of the devices whose contents are authoritative in order that any of the devices can serve the information in the case of unavailability of the original.
This '429 technique has much in common with the distributed ‘Yellow Pages’ database implemented on Sun Microsystems workstations dating back to the mid 1980's. The primary difference is that the identity of a device being available to take on directory service duties need not be configured in advance. Instead, the devices negotiate for authority based upon their assigned network addresses. This in turn is similar to the procedure used by Microsoft in implementing the ‘automatic browse master assignment’ for Windows 95 peer to peer file service. Indeed, almost all of the described capabilities have an equivalent in the ‘browse list’ feature maintained automatically by Windows 95 machines, and which is updated by notification messages sent out on a timed basis by network devices such as printers, computers, and other file server devices.
Similar to '510 patent, the invention of U.S. Pat. No. 5,586,269 ('269) discloses a mechanism that is concerned with assignment of an arbitrary network address that allows the device to become functional on the network. This is accomplished by attempting to contact the existing devices that have been assigned the proposed addresses, in turn, until one is found that is not currently assigned.
The '269 mechanism is not appropriate for use on a TCP/IP local area network because of the problems caused if the address in question actually had been assigned to another device, but that device was temporarily inaccessible. Such a situation would likely cause network disruption and possibly a failure of control in an automation system. Therefore, the '269 methodology would not be acceptable on a network used for automation purposes. Instead, the appropriate protocol to use if an arbitrary address were desired on a TCP/IP local area network is the standard DHCP protocol described in RFC 1531.
The techniques of U.S. Pat. No. 4,677,588 ('588) are not appropriate for TCP/IP local area networks. Assigning appropriate address ranges for network segments which are subsequently linked together is cumbersome, and cannot generally be overcome by defining an address assignment protocol that would be binding upon the existing devices on those networks. The existing TCP/IP devices expect stability in address assignment, and the act of interconnecting two networks cannot by itself, cause reassignment of network addresses without knowledge of the devices themselves. The '588 patent describes a mechanism for more convenient allocation of addresses in a network environment that is not bound by the address assignment conventions of TCP/IP.
U.S. Pat. No. 5,987,524 ('524) describes what is commonly called a network firewall technique to overcome an intended intrusion attack using ‘address spoofing’. The firewall is pre-configured with an association between the physical address of each subscriber device and the IP address assigned to that device. The firewall recognizes the case where an incorrect source network address is being presented by an intruding system, and prevents the messages from being propagated to their intended target device.
The invention of U.S. Pat. No. 5,980,078 ('078) allows a general-purpose network to be used as part of a bootstrapping mechanism to enter the initial configuration data for a device after it has been physically installed on a network, but before it has been made operational. The '078 mechanism is specifically unsuitable for use with arbitrary target devices on a TCP/IP local area network since it relies on assignment of a temporary network address, and a non-operational state known as ‘standby’, in order to allow the device configuration to be completed with manual assistance.
The invention described in U.S. Pat. No. 5,917,808 ('808) is similar to that used in many commercially available network monitoring and system management tools, including ones which have been available on local area networks for more than a decade. Passive monitoring of network traffic to determine the identity and detail configuration of devices is a standard network management and troubleshooting procedure taught to network engineers. Building up a list of discovered devices in a database and displaying the contents of such database on demand is a standard feature of products such as 3Com Corp's ‘Transcend’ management package.
The '808 technique is not appropriate to the problem of automatic reassignment of network IP addresses when a target device is replaced in service, because under those conditions there would be no broadcast traffic to be monitored. In particular, use of Ethernet switching devices on modern networks severely impedes the value of passive monitoring, since only messages designated as ‘broadcast’ or ‘multicast’ are made available by the switches for monitoring by parties other than the direct participants of the communication.
The invention of U.S. Pat. No. 5,845,081 ('081) is concerned with gateway devices that must allow access to information using ‘foreign’ networks. Specifically, by detecting the existence of one or more authoritative devices on the foreign network (the ‘target nodes’), and making queries upon them, the target nodes will divulge information which can be assembled by the gateway in order to ease the configuration of such gateway. This includes pre-assignment of network address equivalence tables or similar data.
A method of allocating addresses on devices without using manual adjustment of switches is described in U.S. Pat. No. 5,680,113 ('113). The '113 patent system does not use switches, relying instead on a known rearrangement of the wiring of an extension cable or connector when connecting such devices in series.
Actually, this '113 mechanism is akin to that used by Modicon Corp (now part of Groupe Schneider) on a product line known as ‘800 series I/O’ introduced with the 884 model Programmable Controller in 1984. In that product, and for exactly the reason mentioned in the patent, the address of one of many modules in a modular I/O rack was determined by a combination of its rack number and slot number within the rack. To allow the racks to be physically identical parts and yet distinguishable in service, the interconnect cable performed a ‘rotation’ of the assignment of 5 signals. The effect of this was that the signals being presented to modules in the individual racks were detectable by the device, and this supplanted the need for any address switches.
U.S. Pat. No. 6,012,088 ('088) describes a technique similar to BOOTP, in which a unique registration number known to the internet access device is presented to a known registration service, which can be accessed without requiring pre-configuration of the device, and obtaining any configuration data from that device. The '088 invention relies on the existence of a known network service access point on the Public Switched Telephone Network, so the initial contact with the registration service can be done using only a previously recorded telephone number and modem settings. From that point onwards, any complex configuration settings can be automated based upon details previously registered in the database or negotiated with the equipment.
Devices that make use of this '088 technique must be specifically designed to do so, because the protocols used are non-standard. The non-standard mechanism is required to handle the case where the device being installed is not on the same local area network as the registration server. If it were on the same network, the same results could have been obtained using the standard protocol BOOTP.
In sum, the problem with prior art systems is that they require involvement of a specialized administrator to oversee the part replacement in order to properly configure the network address. The prior art does not have a simple yet disciplined method to automatically designate proper IP addresses while maintaining the highest level of system integrity. What is needed is an automatic network address assignment system. Such a system would decrease the mean-time-to-repair (MTTR) and allow for field replacement of networked devices without incurring the expense of having a network professional administer the address configuration. Ideally, such a system would use management information gathered from Ethernet switches to deduce physical location information, using such information to deduce the appropriate network address.